Digital Passports System Architecture Overview

A 'Digital Passport System' or 'DP system' is the generic system for which we develop the architecture description. The system comprises IT-components that are generically called digital passports, as well as processes for the governance, management and provisioning thereof.

What is a DP

A digital passport (DP, or just 'passport') is an IT-system (component) whose main function is to securely store data that pertains to a single entity (called the 'subject' of the DP), and to execute code (called 'scripts') that enables such data to be created, read, updated, deleted, archived, etc.

DPs can be diversified into 'digital product passports' or 'DPPs', which are DPs whose data pertains to entities that are classified as a 'product'. We may also use subclassifications thereof, e.g. 'battery', so that a 'digital battery passport' is a digital passport of which the subject is a battery.

Secondary functions of a DP include the storage and execution of code related to scripts and other objects that are relevant for the proper functioning of a DP. Basically, the exchange of data to and from a DP, as well as any processing of such data, is controlled by the set of scripts in a DP. Such functions include, e.g., combining and/or anonymizing data, listing the kinds of data or scripts in a DP, providing data that can be used to identify the DP's subject, participating in cryptographic multi-party computation protocols, etc.

A DP has machine interfaces (APIs) and human interfaces (UIs) that enable it to receive requests for the execution of a script. Also, it has access-control policies (ACPs) that it uses to determine whether or not to service such requests, execution-control policies (ECPs) that it uses to guide the execution of script, and response-control policies (RCPs) that it uses to construct responses for the request and to determine where to send them to and what communications channel/protocol to use.

A DP can be in two states.

• In its initial (unbound) state, it isn't bound to any entity – it has no subject. In this state, a default set of scripts, policies, and data can be installed. Which they are would depend on the kind of entity for which the DP exists and be specified by the rules in the framework that is maintained by the appropriate governance processes.
• In its final (bound) state, the DP is bound to precisely one entity (its subject), and it remains bound to that entity until the DP ceases to exist.

How a DP functions

The essence of a DP is rather simple: it awaits requests, processes such requests, and returns responses. The below figure shows a bit more of the details:

The main parts of a (generic) digital passport

A DP receives requests, either through an API (in case the request is done from some other IT component), or through a UI (in case the request originates from a person). A request specifies a script that it wants the DP to execute, and typically contains additional data as needed by (and specified for) the particular kind of request.

When a DP has received a request of a particular kind, i.e. to execute a specified script, it retrieves the ACP that is associated with that script, and uses it to determine whether or not the request should be serviced.

If it is determined that the request must be serviced, the ECP that is associated with the script is retrieved, and the script is executed accordingly. Any data that may be needed for such execution is typically obtained from either the ECP, or from the request, or from the [DP's] internal data store. The processing of such data produces a result.

If it is determined that the request must not be serviced, a result is produced that indicates an error.

When a result has been produced, the RCP is obtained that is associated with the script, which specifies how, and by means of which communications channel (implying an interface and a protocol), the result will be conveyed as the response to the request.

Using DPs

A DP can be used for any number of mission objectives, some of which are determined by law, while others can be determined by other parties.

When a DP contributes to the realiztion of a mission objective, this implies that a variety of parties need the ability to execute particular scripts on the DP, thereby gaining access to, or process data, according to the role they play to realize that objective. So, for a particular purpose, these roles will need to be defined, the actions need to be specified that these roles may, or must perform, scripts must be authored that the DP can execute in this context, as well as ACPs, ECPs and RCPs, as appropriate. The composition of roles, actions, rights/duties, scripts and policies, is called a Functional Blueprint (FB).

An Active Configuration (AC) represents the real-world deployment of a Functional Blueprint, encompassing not only defined roles, actions, and policies, but also the actual entities assigned to those roles, modifications to policies per DP-owner preferences, and other specifics that translate the blueprint into operational reality.